IBIS Macromodel Task Group Meeting date: 05 May 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Stephen Slater Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Randy noted that we had received a new BIRD198.1 from the authors in Japan. He said he had reviewed it and created a new draft with some editorial changes. He asked that time be allocated to review it at an upcoming meeting. Arpad agreed to add it to the agenda. ------------- Review of ARs: - AR: Radek to send BIRD201 clarification suggestions to Walter. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 28 meeting. Michael moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Gap in IBIS for sampling with statistical mode AMI Models: Hansel shared his presentation about a new BIRD draft, and discussion continued where it left off last meeting. Hansel reviewed open questions. slide 13: Clarifying the description of Rx_Decision_Time Hansel again noted Ambrish's "returned by the model" language and said this leaves the ball in the model developer's court. If the model maker does anything to introduce extra delay, for example, this has to be reflected in the output value of Rx_Decision_Time. Michael said his suggestion had been to adjust the text for clarity in defining exactly what Rx_Decision_Time is. Walter said you know it when you see it, but it might not be easy to define in text. He said in reality we have an IR available, and from that we can create a pulse response. EDA tools look at that pulse response and decide where to put the clock. For some it might be the high point of the pulse response, some might use a hula-hoop algorithm, etc., but you can mark a location on the pulse response plot and say that's where the sampling will occur. Then you can look at all the UI increments to the left and right to formulate eyes, contours, etc. Now, we want to replace that process. Now you take the IR, convolve it with a pulse, and the Rx_Decision_Time tells you where to sample. You have an IR that starts at time zero, a pulse response that starts at time zero, and the Rx_Decision_Time is the time where you want to sample the pulse response. Arpad noted Michael's comment last week about the text's use of "decision point", which in IBIS typically implies a physical location corresponding to the output waveform of Rx GetWave(), where the core logic begins. He suggested that we change "decision point" to "decision time" in this proposal. Walter, Radek and Hansel agreed. Hansel changed all instances to "decision time", and also made the change from mean or median sample time to "ideal sample time" as discussed the previous week. Michael said these changes resolved his question. slide 14: Should we provide any guidance on generation of the pulse response? This question from Ambrish was added at last week's meeting. Ambrish said that we might want to be explicit, for the sake of the model makers and EDA tool vendors, and explain what Walter had described. We might state that one way to generate the pulse response is to convolve the IR with a pulse that starts at t=0. Arpad said he didn't think this was necessary. He said IBIS 7.0 doesn't say that you take the derivative of a step response to get the impulse response, so why would we mention this? Radek noted that this had been discussed during deliberations over BIRD194, and that text had been removed. So, IBIS 7.0 does not discuss it. Arpad noted that BIRD158 type AMI models can use Touchstone files instead of legacy IBIS constructs, so you could conceivably stay in the frequency domain and never have to construct step or pulse responses at all. Walter said if the EDA tool did what we had just described and convolved the output IR with a pulse starting at t=0, then the value of Rx_Decision_Time returned by the model tells the EDA tool where to sample that pulse. He said we all agree on that, and the question is whether we need to put it in the spec. Ambrish said that if someone convolves with a pulse not starting at t=0 then they get a different answer, so we might want to state it explicitly. Since the tool has to know how to apply this value, we need to make sure it's understood the same way by model makers and tool vendors. Walter referred to the Description string in the Example section of the Rx_Decision_Time definition: "The time value in seconds, which is the receiver decision time of the symbol that the threshold crossing started with respect to time zero of the impulse response." He said this description makes the intent clear. Its just talking about the rising transition and we don't even need to mention the difference between step or pulse responses. Radek said that, to be precise, we are talking about a pulse with a rising edge at t=0 and a width equal to the UI. An IR is by definition the response to a delta at t=0. So we can talk about a pulse response instead of an impulse response. Arpad asked how Ambrish could be worrying about different delays being introduced. He said if you take the IR returned by the model and integrate it to get the step response, where can different delays be introduced? Curtis clarified that Ambrish was talking about generating the pulse response directly by convolving the IR with a pulse, and he was concerned about someone using a pulse that didn't start at t=0 and introducing artifical "delay" in the pulse response. Ambrish agreed. Walter said you can do two different convolutions with the IR. One with a step and one with a pulse. If you overlay them, the leading edge of the pulse response will be almost identical to the leading edge of the step response. The only time they wouldn't agree is if there are causality issues (long tail to the left of the IR). The leading edge of the pulse response should be identical to the leading edge of a step response that started at the same time. Radek agreed and said the delay is built into the impulse response. Ambrish said that if everyone thought it was clear that the steps and or pulses started at t=0, then he would drop the issue. However, if there was any room for confusion then we should be explicit. Ambrish briefly searched IBIS 7.0 and said that he didn't find any discussion about how the modified IR is to be returned. So, he said if this has always been understood that the step or pulse would start at t=0, then he we could drop his suggestion to explicitly state it. slide 15: Guidance on CDR and PD, or should clock ticks and/or Rx_Decision_Time be mandatory? This question from Arpad was added at the previous meeting. Arpad said that he had made the observation that the GetWave() flow had the same decision time issue if the GetWave() did not return clock ticks. He had asked if we should consider making clock ticks mandatory, so we didn't have to worry about EDA tools implementing their own differing CDRs. Similarly, he had asked if we should consider making Rx_Decision_Time mandatory so EDA tools don't have to decide for themselves. Walter said that as a tool developer he would be happy if the model maker always provided this information, but he didn't think model makers would like it being mandatory. Walter said that if your model only has a ctle, agc, and ffe, and no dfe, then there is no decision time and no need to provide clock ticks. Arpad said the eye diagram still has to be built based on something, even if the model has no dfe. Walter said a redriver model is just taking an analog waveform in and passing an analog waveform out and would not need any clock ticks information. Arpad agreed that a redriver model was a good counter example, but he said it was an exception. Walter said it's another case of whether we want to define or enforce what a "good" model's behavior is. Radek said he thought Arpad had been proposing that this new Rx_Decision_Time parameter could be used in the GetWave() flow if clock ticks were not returned by GetWave(). He thought this was a reasonable suggestion. Arpad said that he had not intended to suggest this at all. He had merely made the observation that an analogous hole existed in the GetWave() flow if the model didn't return clock ticks. Ambrish said the difference was that the GetWave() flow already provided a way for the model to return clock ticks if it wanted to. This Rx_Decision_Time parameter was adding a way for AMI_Init() to return the information if it wanted to. Arpad said that he had merely made the suggestion based on his observation about clock ticks being analogous to Rx_Decision_Time. He didn't want to pursue the topic. Randy said this might be a topic for a different BIRD, or better yet a cookbook topic on what a good model does. Hansel briefly reviewed the BIRD itself. He noted the change to allow type UI as well as Float, which was discussed at the previous meeting. He also noted the description of "ideal" sampling time in the Solution requirements section. He reviewed one new point that had been added: Rx_Decision_Time takes precedence over Rx_Clock_Recovery_Mean for statistical processing. Arpad asked Hansel to incorporate the comments from the meeting and send the presentation and the BIRD draft to the ATM list. Hansel agreed. BIRD201 - Addressing Radek's comments: Radek reviewed his recent email regarding BIRD201 flow clarifications. He said that up to step five everything is clear. He said step 6 was vague, and he thought it could be removed. Radek suggested we explain scenarios involving the different combinations of the simulation type (statistical or time domain) and the BCI_Training_Mode value. For example, even if BCI_Training_Mode is "Dual", if the user is running a statistical simulation it stops after step 5 and does not continue on to time domain. If the user is doing a time domain simulation, but BCI_Training_Mode is "Impulse", then training is over after step 5. What should the tool do if a time domain simulation is being run and BCI_State returns error or fail at the end of Impulse training? We need to explain the expected behavior in all scenarios. Walter said he would work on an updated version to address Radek's concerns. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Arpad to add BIRD198.1 discussion to the agenda. AR: Hansel to email his updated BIRD draft and presentation to the ATM list. AR: Arpad to ask Steve to upload Hansel's documents to the ATM work archives. AR: Walter to work on a BIRD201.1 draft to address Radek's feedback. ------------- Next meeting: 12 May 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives